在datastar網站，找到where in 最好的介紹，也順便釐清了一些概念。

本篇也作為上上一篇，Day13 排序的擴充解釋。

where in

IN 的概念跟MySQL沒什麼不同，如同下面

select * from users where id in (1,2,3);

等於

select * from users where (id =1 or id =2 or id =3);

但是，要特別說明的是在CASSANDRA/SCYLLA，operator有地位之分。

=和in的地位是一樣的。

而其他的 >、<、>=、<=，又稱range operator，地位比=和in差了一些。

同樣都屬於clustering key，順序在越前面的clustering key越高，查詢條件只能在最後的key使用range operator，前面的key搜尋條件，只能用=或in。

舉例來說，設了4個clustering key。

搜尋時，若指定前3個key在where條件，那麼只能在第3個用range operator，前2個不行。

搜尋時，若指定前2個key在where條件，那麼只能在第2個用range operator，前1個不行。

如以下網站給的範例：

CREATE TABLE numbers (
   key int,
   col_1 int,
   col_2 int,
   col_3 int,
   col_4 int,
   PRIMARY KEY ((key), col_1, col_2, col_3, col_4));

key, col_1, col_2, col_3, col_4 都是primary key

key 是partition key

col_1, col_2, col_3, col_4 是clustering key

我們看到的資料長相

key | col_1 | col_2 | col_3 | col_4
-----+-------+-------+-------+-------
 100 |     1 |     1 |     1 |     1
 100 |     1 |     1 |     1 |     2
 100 |     1 |     1 |     1 |     3
 100 |     1 |     1 |     2 |     1
 100 |     1 |     1 |     2 |     2
 100 |     1 |     1 |     2 |     3
 100 |     1 |     2 |     2 |     1
 100 |     1 |     2 |     2 |     2
 100 |     1 |     2 |     2 |     3
 100 |     2 |     1 |     1 |     1
 100 |     2 |     1 |     1 |     2
 100 |     2 |     1 |     1 |     3
 100 |     2 |     1 |     2 |     1
 100 |     2 |     1 |     2 |     2
 100 |     2 |     1 |     2 |     3
 100 |     2 |     2 |     2 |     1
 100 |     2 |     2 |     2 |     2
 100 |     2 |     2 |     2 |     3

(18 rows)

range operator的使用限制，如下只能在col_4用上range query

SELECT * FROM numbers 
WHERE key = 100 
AND col_1 = 1 AND col_2 = 1 AND col_3 = 1
AND col_4 <= 2;

col_2是最後一個條件，所以可以用range query

SELECT * FROM numbers 
WHERE key = 100 AND col_1 = 1
AND col_2 > 1;

實際上系統的儲存方式
看到這樣的說明，有種豁然開朗的感覺

{ “key” : “100”  { 
         “col_1” : “1”  {
                  “col_2” : “1” {
                            “col_3” : “1” { 
                                       “col_4” : “1”, 
                                       “col_4” : “2”, 
                                        “col_4” : “3”  },
                            “col_3” : “2” {
                                      “col_4” : “1”,
                                      “col_4” : “2”,
                                      “col_4” : “3”  } }, 
                  “col_2” : “2” {
                            “col_3” : “2” {
                                      “col_4” : “1”,
                                      “col_4” : “2”,
                                      “col_4” : “3”  } } }, 
         “col_1” : “2”  {
                  “col_2” : “1” {
                            “col_3” : “1” …

因為資料實際儲存的方式是這樣子，所以也導致CASSANDRA/SCYLLA對於查詢和存取的順序，非常執著。

試想一個樹狀結構的資料，若不指定中間節點在哪裡，怎麼去撈末端節點的資料？分散式資料庫不但資料龐大，且可能四散著到處放，讓它全部都看過一輪再挑選出來是不可能的。

也因此range query的方式，對於資料挑選也是某種障礙，因為同樣的資料只會存一個column。

 100 |     1 |     1 |     1 |     1
 100 |     1 |     1 |     1 |     2
 100 |     1 |     1 |     1 |     3

如範例的這3筆資料，在RDBMS裡面我們會視為截然不同的3筆資料。

但是在CASSANDRA/SCYLLA，只有在col_4是3筆不同資料。

當每個欄位都可以用range operator去查詢，可能查詢範圍量級變得不可評估，筆者覺得這是查詢條件要訂得如此嚴苛的主要原因，我們從最根本的資料組織結構，來了解用法後面的道理。

like

CASSANDRA/SCYLLA 有提供like的關鍵字查詢。

SCYLLA 要3.2以後的版本才有提供。

有如RDBMS的like語法，以pattern的方式查詢目標的欄位資訊。

重點說明

1. 使用pattern尋找欄位的字元，是找UTF-8格式。
2. 整個pattern要完全符合，才能查詢到目標資料。(可以視為正規表示式)

參考資料